Interpreter: Moves around the thread and ELF initialization code #5148
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sonicadvance1
force-pushed
the
29
branch
4 times, most recently
from
0d6d43d to
fada64a
Compare
Just keeps it out of the way during some more code changes. NFC
This allows the context and parent thread objects to be created earlier, allowing the VDSO and ELFCodeLoader mapping functions to have a thread object for tracking memory mappings through the regular guest routines. This means that we no longer need to do any form of deferred handling for code caching as all the state is ready early in the initialization process. A little bit of care needed to be taken to ensure we still close the ELFCodeLoader's FDs later and that VDSO unmapping happens before tearing down the parent thread, but overall this is mostly just passing the InternalThreadState object around as normal. I couldn't find any functional regression from this change alongside code caching, but it would be good for @neobrain to double check this.
Execstack enables `READ_IMPLIES_EXEC` and we were accidentally decoupling our expected persona due to the reordering of initialization. This was causing the smc-1-dynamic test to fail because it's testing execstack and our VMA tracking wasn't returning read-write VMAs as executable once these decoupled. Easy fix.
lioncash
approved these changes
Jan 5, 2026
Contributor
lioncash
left a comment
lioncash
left a comment
There was a problem hiding this comment.
LGTM as far as I can tell
Sonicadvance1
added a commit
to Sonicadvance1/FEX
that referenced
this pull request
Jan 7, 2026
Fixes crash in thunks that use callbacks, introduced in FEX-Emu#5148. The dispatcher would call the syscallhandler to get the VDSO thunk callback. But due to reordering initialization, the VDSO thunk would have not been loaded at that point. This would cause thunks that use callbacks to crash with a nullptr exception. Instead, defer the thunk callback pointer loading until the thread starts executing, and load the pointer in to our thread state's pointer struct instead. Didn't get caught in my initial test sweep since I didn't run a Wine game with thunks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows the context and parent thread objects to be created earlier,
allowing the VDSO and ELFCodeLoader mapping functions to have a thread
object for tracking memory mappings through the regular guest routines.
This means that we no longer need to do any form of deferred handling
for code caching as all the state is ready early in the initialization
process.
A little bit of care needed to be taken to ensure we still close the
ELFCodeLoader's FDs later and that VDSO unmapping happens before tearing
down the parent thread, but overall this is mostly just passing the
InternalThreadState object around as normal.
I couldn't find any functional regression from this change alongside
code caching, but it would be good for @neobrain to double check this.